Thanks a lot for the introduction. Thanks for having me. So I am going to talk about

the many roads leading to microservices. This is by the way me and a few other guys in Iceland.

And I'm going to show a few other pictures from Iceland in the process because obviously

we are talking about the roads that we can travel towards microservices. I did write a few books.

So here is a book about continuous delivery that I wrote. It's a very short and practical introduction.

This has been translated into English and has been published at Edison-Wesley and I also wrote a book

about microservices so I guess that's one of the reasons why I'm standing here right now. And that

book has also been translated into English and it's has been published at Edison Westlake. If

you're interested in the subject of microservices here is another book. So this is like a 30 or 40

pages short book about microservices. You can download it for free here. You can also pay me

a dollar but most of the people don't and that's perfectly fine. And this is also available in

German and as I said it's free. So if you just follow the link you can download it there. Okay

so we are going to talk about microservices and obviously the question is what are, oh by the way

before I start, if there are any questions feel free to ask them anytime. There is no way to get

me distracted or anything like that so just feel free to ask any questions that you might have.

Actually I believe if you don't do that I will run out of slides at one point but we'll see. Okay so

talking about microservices obviously the question is what are microservices and that's already a

challenge because there are quite a few different definitions out there and I tried to come up with

my own one and my own one is that they are independently deployable modules. So what I'm

trying to say here is that they're just modules like we are used to. So there's a, as you probably

know, there is a lot of research and a lot of experience with modular programming. It has been

one of the original ways to become more productive in software development. There are all these nice

papers we know that good modules have low coupling and high cohesion and all these kinds of things.

So basically I'm saying it's just a different way to do modules and as I said the reason why

I like that part of the definition is because it basically means that we just do the same thing

that we have been doing for ages. We just do it slightly differently and the way that we do it

differently is that we have individually deployable modules. So while usually you would have modules

written in some programming language and you would have the compiler that compiles, puts together all

those modules and you have one big thing that will be deployed at once as a whole, this is different

for microservices. For microservices it's possible to change a module, let's say a module that is

concerned with order handling in an e-commerce application and that can be independently deployed

from a module that is responsible for billing. So you can do an update to one of those modules and

you just deploy that one module and the rest just stays as it is. Obviously this means that somehow

we can't use the technologies for modularization that we're used to. If you go for the support in

your programming language for modularization you can't do this because obviously they will create

deployment monolith. So we need to have some different technology. So one way of doing that

is Docker. Docker is sort of a lightweight virtualization. So you would have a process,

an individually deployable system with a full file system and you would just be able to deploy

that and you can start and stop it so you can update it and all the other modules, the other

Docker containers would just stay as they are. So that's basically what microservices are and

how they work. So you would have a server or a Docker container, you would have a microservice

running on top of that and you would have another server with another microservice running on top

of that. And that has some pretty neat consequences. So one of the consequences is that you can now use

any technology that you want. So when you say okay each microservice is just a Docker container,

basically you can do everything that Linux or Windows allows you to do. So you can use Java

in one service, you can use a different programming language, Ruby or whatever in a different service

and there are no limits in that regard. So that's quite nice. I'm not trying to say this is something

that you ought to do. I think it's still valuable to have a homogeneous technology stack just to

keep effort low but it's an option. And if you think about it, it's actually quite nice because

that way if you want to migrate away to a new technology, there is no big bang migration that